Hi, good move!

I see that commit 07cd62e is not part of release 0.2.0 and that 0.2.0 is packaged in Arch Linux and derivatives. My vote for considering a new release and a CVE for this. It only takes filling this form: https://cveform.mitre.org/ .

Our invocation of bubblewrap does not pass through the terminal file descriptor, so we do not believe there is any practical exposure to CVE-2017-5226. We would be likely to dispute any CVE filed for that reason.

To be sure I understand: if that is true, why would you want to pass --new-session then? How is exec.Command not passing the controlling terminal to bwrap? Please help me understand what I may be missing.

To be sure I understand: if that is true, why would you want to pass --new-session then?

We do want the setsid effects for other reasons. And it is better to have it anyway, just in case we begin to use PTYs in the future instead of pipes.

How is exec.Command not passing the controlling terminal to bwrap? Please help me understand what I may be missing.

exec.Command just creates an execution object. The actual execution happens here, after stdio redirection is set up to use pipes: https://github.com/chainguard-dev/melange/blob/main/pkg/container/runner.go#L49

We do want the setsid effects for other reasons.

Could you elaborate?

The title "to mitigate CVE-2017-5226" communicates a different picture. I'm confused.